1. Field of the Invention
The present invention relates generally to computer systems.
2. Description of the Background Art
Undesired Retention of Limited Resources
One of the issues involved in information processing on computer systems is the undesired retention of limited resources by computer programs, such as applications or operating systems. Typically, a computer system is comprised of limited resources, regardless of whether the resources are physical, virtual, or abstract. Examples of such resources are CPU cycles, memory, disk space, file descriptors, socket port numbers, database connections or other entities that are manipulated by computer programs.
A computer program may dynamically allocate resources for its exclusive use during its execution. When a resource is no longer needed, it may be released by the program. Releasing the resource can be done by an explicit action performed by the program, or by an automatic resource management system.
Undesired Memory Retention and Memory Leaks
As mentioned above, one example of a managed resource is memory in a computer system that may be allocated to programs at runtime. In other words, this portion of memory is dynamically managed. The entity that dynamically manages memory is usually referred to as a memory manager, and the memory managed by the memory manager is often referred to as a memory “heap.” Portions of the memory heap may be allocated temporarily to a specific program and then freed when no longer needed by the program. Freed portions are available for re-allocation.
In some programming languages and their associated runtimes, such as C and C++ and others, the memory manager functionality is typically provided by the application program itself. Any release of memory no longer needed by the program is controlled by the programmer. Failure to explicitly release unneeded memory results in memory being wasted, as it will not be used by this or any other program. Program errors which lead to such wasted memory are often called “memory leaks.”
In other programming languages and their runtimes, such as Java, Eiffel, C sharp (C#) and others, automatic memory management is employed, rather than explicit memory release. Automatic memory management, popularly known in the art as “garbage collection,” is an active component of the runtime system associated with the implementation of these programming languages and their associated runtimes. Automatic memory management solves the problem of applications that do not explicitly release unneeded memory by automatically returning those unused portions of memory when there are no longer any references from a defined root set of data structures to the data structures allocated by the program in that region of memory.
However, another problem can occur with automatic memory management—the retention of references to the data structures in portions of memory, data structures that will not be used in the future execution of the application. The references to these unused data structures in these areas generally prevent the automatic garbage collector from re-claiming the unused portions of memory. In the common vernacular, undesired memory retention in runtimes that support automatic memory management is also referred to as “memory leaks.” For example, in the Java runtime, these are often referred to as “Java memory leaks.”
It is highly desirable to discover the presence of undesired memory retention in an application. Moreover, after discovering the presence of undesired memory retention in an application, it is highly desirable to quickly find the root cause of the problem and identify the root cause's surrounding context. One can then use this information to fix the problem.
Despite the use of garbage collection, object retention problems, often called “memory leaks,” frequently occur in Java applications. This undesired object retention may eventually cause a Java application to crash when all memory resources are consumed. In the short term, the runtime's management of large numbers of unused objects causes application slow-down and higher costs for the application in production deployment. Similarly, applications based on other programming languages and runtimes also have similar resource consumption problems.
It has been determined that undesired object retention (a memory leak) occurs when there are references to an object that make that object reachable from a set of root objects in the application, but the object will never be used again by the application. In that case, the application could use the object if needed, but the application does not use the object, so keeping the object in memory is a waste of memory.
The object that is able to be referenced from the root set of objects in the application through either direct or indirect references is frequently referred to as a “live” object. Other means or techniques of determining liveness also exist, including reference counting, and these alternate techniques may also be used.
For example, a Java application may create objects during a Java Enterprise Edition, also referred to as J2EE (Java 2 Platform Enterprise Edition), transaction and inadvertently cache references to these created objects. If these objects are no longer used by the application after the completion of the transaction, the references to the objects remain in the cache, and the cache itself remains reachable from the root set of objects, then these transaction-related objects continue to occupy memory—undesired object retention. In this case, a little more free (or unused) memory is lost (leaked) each time the application performs such a J2EE transaction.
Moreover, such memory leaks frequently occur in deployed web and mission-critical applications that are actively serving customers. The resultant crashes that occur when no additional memory is available for the application directly impact customer service and sales.
Existing solutions to the above discussed problem are typically too intrusive to the application and/or do not give an operator enough information about the root cause and context of the undesired object retention (memory leak). Most of the existing solutions for locating retained objects are applicable only in development environments because i) their high overhead would be too intrusive to use with a deployed application in production, ii) their need for user interaction to help in determining the undesired object retention's root cause and context, and/or iii) their lack of scalability.
Memory leak analysis of a running application should preferably be performed with very low performance degradation, typically no more than about 5 percent usage of the critical program resources when the production system is highly utilized. In addition, the application should not be made to pause for several seconds, and the analysis should not require large amounts of memory.
In addition, operators of data centers, where web or other mission-critical applications are frequently hosted, are under pressure to diagnose problems quickly but the users themselves may not have sophisticated debugging knowledge. As such, it is desirable to be able to indicate to a data center operator exactly where memory leaks may be occurring, and to give such indication as early as possible. Root cause analysis and identification of the context of the problem in the production environment helps to reduce the overall cost of fixing the problem by enabling quick re-configuration or defect-repair of the application. Such detailed diagnosis avoids the requirement for costly, and often unsuccessful, attempts to recreate the problem in the development environment.